前言
第四階段最後一天,我們要把前面幾天(除錯、版本控制、A/B Testing)反覆出現的一個原則,正式獨立出來講清楚:修改範本時,為什麼應該針對單一問題局部調整,而不是一遇到問題就想整份重寫?
這個心法看似只是工作習慣,但它其實直接決定了你的範本能不能長期穩定維護下去。

一、「整份重寫」的誘惑從哪裡來
當你發現輸出結果不如預期,尤其是連續幾次修正都沒完全解決問題時,很容易冒出一個念頭:「乾脆整份砍掉重練,說不定比較快。」這個衝動可以理解——面對一份規則堆疊、看起來越來越複雜的 System Prompt,重寫確實給人一種「終於可以乾淨俐落解決問題」的錯覺。
但這個做法,有兩個實際的隱藏代價。
二、代價一:你會弄丟過去所有除錯經驗的成果
回顧 Day 22 談過的修改日誌——如果你的範本累積了 20 次修正,每一次都是針對某個真實測試中發現的問題而調整的。整份重寫,等於把這 20 次修正的成果全部歸零,重新開始。你很可能會在新版本裡,重新踩到過去已經解決過的坑——因為那些「已經處理過的例外情況」,只存在於舊版的規則裡,而不是存在於你的記憶中。
三、代價二:你無法定位「到底是哪裡真的有問題」
這是更根本的原因。呼應 Day 21 除錯、Day 23 A/B Testing 反覆強調的邏輯:只有一次改一個地方,你才能確定「這個改動,對應到那個問題」。 如果整份重寫,新版本跟舊版本之間的差異太大,即使新版本測試起來變好了,你也說不清楚到底是哪個改動真正解決了問題——這代表你這次的「修好」,其實是運氣,而不是真正掌握了問題的根源。下次遇到類似狀況,你依然無法快速判斷該怎麼處理。
四、局部修改的具體操作方式
延續 Day 21 建立的除錯流程,局部修改的標準動作是:

1. 精準定位:對照 Day 5 品質檢查清單,確認問題出在哪一個具體面向(格式、內容、語氣中的哪一項)
2. 回推規則:找出範本裡,負責處理這個面向的那一段具體規則(例如語氣問題,回頭找 Day 9 的禁用清單那一段)
3. 只調整那一段:修改幅度盡量限縮在這段規則本身,不去動其他運作正常的部分
4. 重新測試同一情境:確認問題解決,同時檢查其他原本正常的部分有沒有被意外影響(這正是 Day 23 A/B Testing 存在的原因)
5. 記錄到修改日誌:完成 Day 22 提過的紀錄動作
   五、什麼情況下,「大幅調整」才是合理的?
   局部修改不代表永遠不能做大幅度的調整。如果你發現同一類問題反覆出現、局部修補了好幾次都沒能根治,這反而是一個訊號——代表問題可能不是某一條規則寫得不夠精確,而是整體架構設計上有更根本的缺陷(例如骨架與血肉的切分方式一開始就不合理)。這種情況下,經過深思熟慮後的大幅調整才有正當性——但即使如此,也建議透過 Day 23 的 A/B Testing 方式,正式比較新舊架構的差異,而不是憑一時衝動就砍掉重練。
   判斷標準很簡單:大幅調整應該是「診斷後的結論」,而不是「遇到挫折時的情緒反應」。
   六、這個心法背後,呼應的是整個系列的核心精神
   回到 Day 1 的比喻——AI 是產線員工,你在寫規格書。一份成熟的規格書,不會因為某個環節出了小問題就整份作廢重寫,而是針對出問題的那一條規格條文做修正。這也是為什麼 Day 2 談的「工程」思維如此重要:工程師面對 bug,是定位、修復、驗證,而不是每次都重新設計整個系統。
   七、今天的行動練習
   回顧你這幾天做的所有修改,誠實檢視:有沒有哪一次,你其實是「順手改了好幾個地方」,而不是精準定位單一問題?如果有,試著回想那次修改,拆解出「如果只改一處,應該改哪裡」,作為未來遇到類似狀況時的參考。

小結
第四階段到這裡全部完成了。這六天,我們從組裝第一版範本、真實資料壓力測試,到系統化除錯、版本控制、A/B Testing,最後今天收斂成一個核心紀律:局部修改、精準定位、拒絕靠重寫逃避真正的問題。 這個心法,會是你未來長期維護這份範本時,最重要的工作習慣。
最後一個階段,我們要把單純的 Prompt 範本,升級成真正的自動化系統——從跨出介面的第一步(API 概念)開始談起。